In a typical clustered enterprise level application server environment, clients may access the cluster using the Internet Interoperability Protocol (IIOP). FIG. 1 shows an example of such a clustered system. The cluster 100 comprises a number of servers or cluster members C1 102, C2 104, C3 106, each of which can be identified by an object request (IOR) specifying the servers name or address, and a port identifier. The client 108 makes IIOP requests 110 upon the cluster using tunneled IIOP. The problem is that this only works when the client communicates directly with the cluster and no proxy is involved. If, as is shown in FIG. 1, a proxy 114 is involved then the situation becomes more complicated:
Proxy's that are hardware load balancers are unable to route requests to specific servers. They can only pick servers at random and then use some form of “stickiness” in the http header information. Client-side clustering relies on the ability to route to specific servers;
Proxy's generally perform Network Address Translation (NAT), requiring that cluster member (IOR's) advertise the address of the proxy rather than the actual external addresses of the cluster members. So whereas in the example shown in FIG. 1, each of the cluster members C1 through C3 have a distinct address and port, the proxy can only advertise a single address and port to the client;
Unsigned applets can only open connections to the servers that can be accessed.
In order to provide efficient load-balancing and failover throughout the enterprise, there exists a need for a mechanism by which tunneled IIOP clients can work in clustered environment.